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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document creates an Internet Assigned Number Authority (IANA) 
registry for tel Uniform Resource Identifier (URI) parameters and 
their values. It populates the registry with the parameters defined 
in the tel URI specification, along with the parameters in tel URI 
extensions defined for number portability and trunk groups. 
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Introduction 
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defines a URI that can be used to 

The tel URI, 
provides extensibility through the definition 
and new values for existing parameters. 

not specify an IANA registry where such 

can be listed and standardized. This 

such a registry. 


[1]), 


"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
, "RECOMMENDED", "MAY", and "OPTIONAL" in this 
erpreted as described in [2]. 


and values for these parameters MUST be 
other permanent and readily available public 
to be registered by IANA. This documentation 
syntax, intended usage, and semantics of the 
of this requirement is to assure 
en independent implementations, and to prevent 
ollisions between implementations of dissimilar 


URI parameters or parameter values MUST 

as described in Section 4. The IANA 

r such parameters is "Specification Required, 
d is further discussed in Section 4.2. 


s only accept a set of predefined parameter 
n take any value. There are also parameters 
alue; they are used as flags. 


hat take on predefined values typically take on 
es. Registering each of those values, or 

y for each such parameter is not appropriate. 

n to register URI parameter values by 

he entry in the URI parameter registry for a 
ntains references to the RFCs defining new 

er. 


the tel URI parameter registry contains a column that 


ot each parameter accepts a value. The column 
or "Constrained". A "Constrained" in the 
rtain predefined values exist for this 
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parameter and the accompanying RFC or other permanent and readily 
available public specification should be consulted to find out the 
accepted set of values. A "No Value" in the column implies that the 
parameter is used either as a flag, or does not have a set of 
predefined values. The accompanying RFC or other permanent and 
readily available public specification should provide more 
information on the semantics of the parameter. 

4. IANA Considerations 


The specification creates a new IANA registry named "tel URI 
Parameters". 


4.1. tel URI Parameters Registry 


New tel URI parameters and new values for existing tel URI parameters 
MUST be registered with IANA. 


When registering a new tel URI parameter, the following information 
MUST be provided: 


o Name of the parameter. 
o Whether the parameter only accepts a set of predefined values. 


o Reference to the RFC or other permanent and readily available 
public specification defining the parameter and new values. 


When registering a new value for an existing tel URI parameter, the 
following information MUST be provided: 


o Name of the parameter. 


o Reference to the RFC or other permanent and readily available 
public specification providing the new value. 


Table 1 contains the initial values for this registry. 
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Parameter Name Predefined Values Reference 
isub Constrained [RFC3966] 
isub-encoding Constrained [RFC4715] 
ext Constrained [RFC3966] 
phone-context Constrained [RFC3966] 
enumdi No value [RFC4759] 
npdi No value [RFC4694] 
rn Constrained [RFC4694] 
rn-context Constrained [RFC4694] 
cic Constrained [RFC4694] 
cic-context Constrained [RFC4694] 
tgrp Constrained [RFC4904] 
trunk-context Constrained [RFC4904] 


Table 1: IANA tel URI parameter registry 
4.2. Registration Policy for tel URI Parameters 


As per the terminology in [3] and actions accorded to such a role, 
the registration policy for tel URI parameters shall be 
"Specification Required, Designated Expert" (the former implicitly 
implies the latter). 


The Designated Expert, when deliberating on whether to include a new 
parameter in the tel URI registry, may use the criteria provided 
below to reach a decision (this is not an exhaustive list but 
representative of the issues to consider when rendering an equitable 
decision): 


o If the tel URI -- with the parameter under consideration -- will 
be converted to a URI used by other signaling protocols such as 
the Session Initiation Protocol (SIP [5]) or H.323 [7], then the 
expert must consider whether this parameter merely encapsulates 
signaling information that is not meaningful to the processing of 
requests in the domain of the converted URI. For example, certain 
Integrated Services Digital Network (ISDN) User Part (ISUP, [8]) 
parameters have no equivalent corollary in SIP; thus, their 
presence or absence in a SIP URI will not hinder the normal rules 
for processing that URI. Other parameters may affect the normal 
processing rules associated with the URI; in such cases, the 
expert must carefully consider the ramifications, if any, of the 
presence of such parameters. 


o Certain parameters of a tel URI can be optional. These parameters 
act as metadata about the identifier in the tel URI. Optional 
parameters should provide additional information to a service for 
which they apply instead of acting as enablers of that service in 
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the first place. The service must continue to be invoked and 
operate normally even in the absence of these parameters. 

5. Security Considerations 


The registry in this document does not in itself have security 


considerations. However, as mentioned in [4], an important reason 
for the IETF to manage the extensions of SIP is to ensure that all 
extensions and parameters are able to provide secure usage. The 


supporting RFC publications for parameter registrations described in 
this specification MUST provide detailed security considerations for 
them. 
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